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Abstract. Language-based information flow methods offer a principled way to enforce 
strong security properties, but enforcing noninterference is too inflexible for realistic appli- 
cations. Security-typed languages have therefore introduced declassification mechanisms 
for relaxing confidentiality policies, and endorsement mechanisms for relaxing integrity 
policies. However, a continuing challenge has been to define what security is guaranteed 
when such mechanisms are used. This paper presents a new semantic framework for ex- 
pressing security policies for declassification and endorsement in a language-based setting. 
The key insight is that security can be characterized in terms of the influence that de- 
classification and endorsement allow to the attacker. The new framework introduces two 
notions of security to describe the influence of the attacker. Attacker control deflnes what 
the attacker is able to learn from observable effects of this code; attacker impact captures 
the attacker's influence on trusted locations. This approach yields novel security condi- 
tions for checked endorsements and robust integrity. The framework is flexible enough to 
recover and to improve on the previously introduced notions of robustness and qualified 
robustness. Further, the new security conditions can be soundly enforced by a security 
type system. The applicability and enforcement of the new policies is illustrated through 
various examples, including data sanitization and authentication. 



1. Introduction 

Many common security vulnerabilities can be seen as violations of either confidentiality or 
integrity. As a general way to prevent these information security vulnerabilities, information 
flow control has become a popular subject of study, both at the language level |2^ and at the 
operating-system level (e.g., |14| [T2| I30|). The language-based approach holds the appeal 
that the security property of noninterference |13j . can be provably enforced using a type 
system |27) . In practice, however, noninterference is too rigid: many programs considered 
secure need to violate noninterference in limited ways. 

Using language-based downgrading mechanisms such as declassification [17' "21] and en- 
dorsement [20, .29] ■ programs can be written in which information is intentionally released, 
and in which untrusted information is intentionally used to affect trusted information or 
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decisions. Declassification relaxes confidentiality policies, and endorsement relaxes integrity 
policies. Both endorsement and declassification have been essential for building realistic ap- 
plications, such as various applications built with Jif |15|I18|: games [5], a voting system |11| . 
and web applications [9j. 

A continuing challenge is to understand what security is obtained when code uses down- 
grading. This paper contributes a more precise and satisfactory answer to this question, par- 
ticularly clarifying how the use of endorsement weakens confidentiality. While much work 
has been done on declassification (usefully summarized by Sands and Sabelfeld [24j). there 
is comparatively little work on the interaction between confidentiality and endorsement. 

To see such an interaction, consider the following notional code example, in which a 
service holds both old data (old_data) and new data (new_data), but the new data is not 
to be released until time einbargo_tiine. The variable new_data is considered confidential, 
and must be declassified to be released: 

if request-time >= einbargo_time 
then return declassify (new_data) 
else return old_data 

Because the requester is not trusted, the requester must be treated as a possible attacker. 
Suppose the requester has control over the variable request_tinie, which we can model by 
considering that variable to be low-integrity. Because the intended security policy depends 
on request_tiine, the attacker controls the policy that is being enforced, and can obtain 
the confidential new data earlier than intended. This example shows that the integrity 
of request_tinie affects the confidentiality of new_data. Therefore, the program should 
be considered secure only when the guard expression, request_time >= embargo_tinie, is 
high-integrity. 

A different but reasonable security policy is that the requester may specify the request 
time as long as the request time is in the past. This policy could be enforced in a language 
with endorsement by first checking the low-integrity request time to ensure it is in the 
past; then, if the check succeeds, endorsing it to be high-integrity and proceeding with the 
information release. The explicit endorsement is justifiable because the attacker's actions 
are permitted to affect the release of confidential information as long as adversarial inputs 
have been properly sanitized. This is a common pattern in servers that process possibly 
adversarial inputs. 

Robust declassification has been introduced in prior work f28| [161 113 &s a semantic 
condition for secure interactions between integrity and confidentiality. The prior work also 
develops type systems for enforcing robust declassification, which are implemented as part 
of Jif [TB]. However, prior security conditions for robustness are not satisfactory, for two 
reasons. First, these prior conditions characterize information security only for terminating 
programs. A program that does not terminate is automatically considered to satisfy robust 
declassification, even if it releases information improperly during execution. Therefore the 
security of programs that do not terminate, such as servers, cannot be described. A second 
and perhaps even more serious limitation is that prior security conditions largely ignore the 
possibility of endorsement, with the exception of qualified robustness |16| . Qualified robust- 
ness gives the endorse operation a somewhat ad-hoc, nondeterministic semantics, to reflect 
the attacker's ability to choose the endorsed value. This approach operationally models what 
the attacker can do, but does not directly describe the attacker's control over confidentiality. 
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The introduction of nondeterminism also makes the security property possibihstic. How- 
ever, possibihstic security properties have been criticized because they can weaken under 
refinement [221 125] . 

The main contribution of this paper is a general, language-based semantic framework 
for expressing information flow security and semantically capturing the ability of the at- 
tacker to influence both the confidentiality and integrity of information. The key building 
blocks for this semantics are attacker knowledge [1\ and its (novel) dual, attacker impact, 
which respectively describe what attackers can know and what they can affect. Building 
upon attacker knowledge, the interaction of confidentiality and integrity, which we term 
attacker control, can be characterized formally. The robust interaction of confidentiality 
and integrity can then be captured cleanly as a constraint on attacker control. Further, 
endorsement is naturally represented in this framework as a form of attacker control, and a 
more satisfactory version of qualified robustness can be defined. All these security conditions 
can be formalized in both progress-sensitive and progress-insensitive variants, allowing us to 
describe the security of both terminating and nonterminating systems. 

We show that the progress-insensitive variants of these improved security conditions 
are enforced soundly by a simple security type system. Recent versions of Jif have added a 
checked endorsement construct that is useful for expressing complex security policies [9] , but 
whose semantics were not precisely defined; this paper gives semantics, typing rules and a 
semantic security condition for checked endorsement, and shows that checked endorsement 
can be translated faithfully into simple endorsement at both the language and the semantic 
level. Our type system can easily be adjusted to enforce the progress-sensitive variants of 
the security conditions, as has been shown in the literature |26| 119) . 

The rest of this paper is structured as follows. Section [2] shows how to define in- 
formation security in terms of attacker knowledge. Section [3] introduces attacker control. 
Section [4] defines progress-sensitive and progress-insensitive robustness using the new frame- 
work. Section |5] extends this to improved definitions of robustness that allow endorsements, 
generalizing qualified robustness. A type system for enforcing these robustness conditions 
is presented in Section |6] The checked endorsement construct appears in Section [7j which 
introduces a new notion of robustness that allows checked endorsements, and shows that 
it can be understood in terms of robustness extended with simple endorsements. Section [8] 
introduces attacker impact. Additional examples are presented in Section l9) related work is 



discussed in Section 10 and Section 11 concludes. 

This paper is an extended version of a previous paper by the same authors [4j. The 
significant changes include proofs of all the main theorems, a semantic rather than syntactic 
definition of fair attacks, and a renaming of "attacker power" to "attacker impact". 

2. Semantics 

Information flow levels. We assume two security levels for confidentiality — public and 
secret — and two security levels for integrity — trusted and untrusted. These levels are 
denoted respectively P,§ and T,U. We define information flow ordering C between these 
two levels: PCS, and T C U. The four levels define a security lattice, as shown on Figure [T] 
Every point on this lattice has two security components: one for confidentiality, and one for 
integrity. We extend the information flow ordering to elements on this lattice: ii C I2 if the 
ordering holds between the corresponding components. As is standard, we define join ii U^2 
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Figure 1. Informa- 
tion flow lattice 
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e ::= n \ x \ e op e 

c ::= skip \ x := e \ c;c 

I if e then ci else C2 | while e do c 

Figure 2. Syntax of the language 



(ei,m) I vi {e2,m) 1 1;2 



W = fl op V2 



(ei op 62, m) I u 
Figure 3. Semantics of expressions 

(e, m) J, ?; 



(x := e,m) — >(^^^^){stop,m[x ^ v]) 

(ci,m) — >t{stop,m) 
(ci;c2,m) — >t{c2,m') 

{e,m) I n n = 
(if e then ci else C2,m) — >{c2,m) 

{e,m) I n n = 



(skip, m) — >{stop, m) 

(ci,m) — >t{c'i,m') 
(ci;c2,m) — ;>i(ci;c2,m') 

(e,7n) ^ n n 7^ 
(if e then ci else C2,m) — >{ci,m) 

{e,m) \, n n 7^ 
(while e do c, m) — ;'(c; while e do c,m) (while e do c, ttt.) — >{stop,m) 

Figure 4. Semantics of commands 

as the least upper bound of ii and £2 , and meet ii n £2 as the greatest lower bound of ii and 
£2- All four lattice elements are meaningful; for example, it is possible for information to 
be both secret and untrusted when it depends on both secret and untrusted (i.e., attacker- 
controlled) values. This lattice is the simplest possible choice for exploring the topics of this 
paper; however, the results of this paper straightforwardly generalize to the richer security 
lattices used in other work on robustness llOI. 



Language and semantics. We consider a simple imperative language with syntax presented 
in Figure |2] The semantics of the language is fairly standard and is given in Figures [3] 
and pi For expressions, we define big-step evaluation of the form (e, m) \, v, where v is 
the result of evaluating expression e in memory m. For commands, we define a small-step 
operational semantics, in which a single transition is written as {c,m) — >t{c',m'), where c 
and m are the initial command and memory, and c' and m' are the resulting command and 
memory. The only unusual feature is the annotation t on each transition, which we call 
an event. Events record assignments: an assignment to variable x of value v is recorded 
by an event {x,v). This corresponds to our attacker model, in which the attacker may 
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only observe assignments to public variables. We write {c,m) — ?f to mean that trace t 
is produced starting from (c, m) using zero or more transitions. Each trace t is composed 
of individual events ti-t2- ■ -tk ■ ■ ■ , and a prefix of t up to the i-th event is denoted as ti] 
we use the operator • to denote the concatenation of two traces or events. If a transition 
does not affect memory, its event is empty, which is either written as e or is omitted, e.g.: 
(c, m) — >{c' ,m'). 

Finally, we assume that the security environment V maps program variables to their 
security levels. Given a memory m, we write mp for the public part of the memory; similarly, 
mj is the trusted part of m. We write m =f m! when memories m and m' agree on their 
trusted parts, and m =p m! when m and m! agree on their public parts. 

2.1. Attacker knowledge 

This section provides background on the attacker-centric model for information flow secu- 
rity [1]. We recall definitions of attacker knowledge, progress knowledge, and divergence 
knowledge, and introduce progress- (in)sensitive release events. 

Low events. Among the events that are generated during a trace, we distinguish a sequence 
of low (or public) events. Low events correspond to observations that an attacker can 
make during a run of the program. We assume that the attacker may observe individual 
assignments to public variables. Furthermore, if the program terminates, we assume that a 
termination event -IJ- may also be observed by the attacker. If attacker can detect divergence 



of programs (cf. Definition 2.3) then divergence f^ is also a low event. 

Given a trace t, low events in that trace are denoted as tp. A single low event is often 
denoted as i, and a sequence of low events is denoted as i. We overload the notation 
for semantic transitions, writing {c,m) — ?f if only low events produced from configuration 
{c,m) are relevant; that is, there is a trace t such that {c,m) — f^-A tp = i. Low events are 
the key element in the definition of attacker knowledge [1\. 

The knowledge of the attacker is described by the set of initial memories compatible 
with low observations. Any reduction in this set means the attacker has learned something 
about secret parts of the initial memory. 

Definition 2.1 (Attacker knowledge). Given a sequence of low events i, initial low memory 
mp, and program c, attacker knowledge is 

k{c,7np,£) = {m \ mp = m'p A {c,m) — f^} 

Attacker knowledge gives a handle on what information the attacker learns with every low 
event. The smaller the knowledge set, the more precise is the attacker's information about 
secrets. Knowledge is monotonic in the number of low events: as the program produces low 
events, the attacker may learn more about secrets. 

Two extensions of attacker knowledge are useful: progress knowledge [3l[2] and divergence 
knowledge [3\. 

Definition 2.2 (Progress knowledge). Given a sequence of low events i, initial low memory 
mp, and a program c, define progress knowledge k^{c,mp,i) as 

k^{c,mf>,i) = {m' I m'-p = mp A 3/ . {c,m) — >*^c",m") — ?£'} 
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Progress knowledge represents the information the attacker obtains by seeing pubhc events i 
followed by some other public event. Progress knowledge and attacker knowledge are related 
as follows: given a program c, memory m and a sequence of low events ii- ■ ■ in obtained 
from (c, ?n,), we have that for all i < n, 

k{c,mp,ii) D A;^(c,mp,£j) D A;(c,mp,^j+i) 

To illustrate this with an example, consider program / := 0; (while h = do skip); / := 
h with initial memory m(h) = 7. This program produces a sequence of two low events 
{I, 0)-(/, 7). The knowledge after the first event k{c, mp, (/, 0)) is a set of all possible memories 
that agree with m on the public parts and can produce the low event (Z,0). Note that no 
low events are possible after the first assignment unless h is non-zero. Progress knowledge 
reflects this: /c_>(c, mp, (/,0)) is a set of memories such that h ^ 0. Finally, the knowledge 
after two events k{c, mp, (l, 0) • (/, 7)) is a set of memories where h = 7. 

Using attacker knowledge, one can express many confidentiality policies [71 EJ |8j. For 
example, a strong notion of progress-sensitive noninterference |13] can be expressed by de- 
manding that knowledge between low events does not change: 

k{c, mp, ii) = k{c, mp, £j+i) 

Progress knowledge enables expressing more permissive policies, such as progress-insensitive 
noninterference, which allows leakage of information, but only via termination channels (in 
^ it is called termination-insensitive) . This is expressed by requiring equivalence of the 
progress knowledge after seeing i events with the knowledge obtained after i -\- 1-th event: 

k^{c,mp,ii) = k{c,mp,£i+i) 

In the example I := 0; (while h = do skip); / := 1, the knowledge inclusion between the 
two events is strict: k{c,mp, (^,0)) D k{c,mp, {l,0)-{l, 1)). Therefore, the example does not 
satisfy progress-sensitive noninterference. On the other hand, the low event that follows 
the while loop does not reveal more information than the knowledge about the existence 
of that event. Formally, k^{c,mp, (1,0)) = k(c,mp, {l,0)-{l, 1)), hence the program satisfies 
progress-insensitive noninterference. 

These definitions also allow us to reason about knowledge changes along parts of the 
traces. We say that knowledge is preserved in a progress-(in)sensitive way along a part 
of a trace, assuming that the respective knowledge equality holds for the low events that 
correspond to that part. 

Next, we extend possible observations to a divergence event f^ (we write {c,m) f^ to 
mean configuration {c,m) diverges). For attackers that can observe program divergence ff, 
we define knowledge on the sequence of low events that includes divergence: 

Definition 2.3 (Divergence knowledge). 

k{c, mp,/fr) = {m' \ mp = mpA {a, m') — ^ /.c" , m") A (c", m") fr} 

Note that the above definition does not require divergence immediately after i — it allows 
for more low events to be produced after i. Divergence knowledge is used in Section |4J 

Let us consider events at which knowledge preservation is broken. We call these events 
release events. 

Definition 2.4 (Release events). Given a program c and a memory m, such that 

{c,m) — fAc,m') — fr 
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• r is a progress-sensitive release event, if k{c,mf,l) D k(c,mp,i-r) 

• r is a progress-insensitive release event, if k^(c,mp,i) D k{c,mf>,i-r) 

It is easy to validate that a progress-insensitive release event is also a progress-sensitive 
event. For example, in the program low := 1; low' := h, the second assignment is both a 
progress-sensitive and a progress-insensitive release event. The reverse is not true — in the 
program while h = do skip; low := 1 the assignment to low is a progress-sensitive release 
event, but is not a progress-insensitive release event. 

3. Attacks 

To reason about program security in the presence of active attacks, we introduce a formal 
model of the attacker. Our formalization follows that in [16], where attacker-provided code 
can be injected into the program. This section provides examples of how attacker-injected 
code may affect attacker knowledge, followed by a semantic characterization of the attacker's 
influence on knowledge. 

First, we extend the syntax to allow execution of attacker-controlled code: 



Next, we introduce notation [t] to highlight that the trace t is produced by attacker- 
injected code. The semantics of the language is extended accordingly. 

{a,m) — h{a,m') 
—- ^ -— — {[stop\,m} — >{stop,m) 

We limit attacks that can be substituted into holes to so-called fair attacks, which represent 
reasonable limitations on the impact of the attacker. Unlike earlier approaches, where fair 
attacks are defined syntactically |16| llOj . we define them semantically. This allows us to 
include a larger set of attacks. To ensure that we include all syntactic attacks we make use 
of a reachability translation, explained below. 

Roughly, we require a fair attack to not give new knowledge and to not modify trusted 
variables. A refinement of this idea is that an attack is fair if it gives new knowledge but 
only because the reachability of the attack depends on a secret. To capture this refinement, 
we define an auxiliary translation to make reachability of attacks explicit. We assume a 
trusted, public variable reach that does not appear in the source of c[»]. Let operator T^ 
be a source-to-source transformation of c[»] that makes reachability of attacks explicit. 

Definition 3.1 (Explicit reachability translation). Given a program c[«], define (T^(c[»]) 
as follows: 

• T^([»]) =^ reach := reach -|- 1; [•] 

• T^(ci;c2) ^ T^(ci);T^(c2) 

• T^(if e then ci else C2) =^ if e then T^(ci) else T^(c2) 

• T^ (while e do c) =^ while e do T^(c) 

• T^(c) =^ c for all other commands c 

The formal definition uses that any trace t can be represented as a sequence of subtraces 
ti ■ [^2] • • • t2*n-i ■ [t2*n], where even-numbered subtraces correspond to the events produced 
by attacker-controlled code. 

Given a trace t, we denote the trusted events in the trace as tj. We use notation t^ for 
a single trusted event, and t^, for a sequence of trusted events. 
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Definition 3.2 (Fair attack). Given a program c[»], sucli tliat T^(c[»]) =^ c^[*], say 
tliat a is a fair attack on c[»] if for all memories m, such that {c^[a],m) — ?^ and t = 
ti-[t2] ■ ■ ■ t2*n-i'[t2*n], i-^., there are 2n intermediate configurations {cj, rrij), 1 < j < 2n, for 
which 

{C^[a],m) ?^- (Ci,mi) ?[t-](c2, ^-2) >%- • • • ^*[r2^](c2n,"l2n) . . . 

then for all z, 1 < i < n, it holds that k(c^[a], m,ti- ■ ■ t2i-i) = k{c^[d],m, ti • • • [t2j]) and 

For example, in the program if /i > then [•] else skip the attacks ai = [low := 1] 
and attack 02 = [low := h > 0] are fair, but attack 03 = [low := h] is not. 

3.1. Examples of attacker infiuence 

This section presents a few examples of attacker influence on knowledge. We also introduce 
pure availability attacks and progress attacks, to which we refer later in this section. 

In the examples below, we use notation [(u, v)] when a low event (n, v) is generated by 
attacker-injected code. 

Consider program [•]; low := u > h; where h is a secret variable, and u is an untrusted 
public variable. The attacker's code executes before the low assignment and may change 
the value of u. Consider memory m, where m(h) = 7, and the two attacks ai = u := and 
a2 = u := 10. These attacks result in different values being assigned to variable low. The 
first trace results in low events [(u,0)]-{low,0), while the second trace results in low events 
[(n, 10)]-(/ou', 1). Therefore, the knowledge about the secret is different in each trace. We 
have 

k{c[ai],mp,[{u,0)]-{low,0)) = {m \ m{h) > 0} 

k{c[a2],mv,[{u,m)]-{low ,1)) = {m \ m{h) < 10} 

Clearly, this program gives the attacker some control over what information about secrets 
he learns. Observe that it is not necessary for the last assignment to differ in order for the 
knowledge to be different. For example, consider attack 03 = n := 5. This attack results 
in low events [{u,5)]-{low,0), which do the same assignment to low as ai does. Attacker 
knowledge, however, is different from that obtained by oi: 

k{c[a3],mp, [(n, 5)]-{low, 0)) = {m \ m{h) > 5} 

Next, consider program [•]; low := h. This program gives away knowledge about the value 
of h independently of untrusted variables. The only way for the attacker to influence what 
information he learns is to prevent that assignment from happening at all, which, as a result, 
will prevent him from learning that information. This can be done by an attack such as 
a = while true do skip, which makes the program diverge before the assignment is reached. 
We call attacks like this pure availability attacks. Another example of a pure availability 
attack is in the program [•]; (while u = do skip); low := h. In this program, any attack 
that sets n to prevents the assignment from happening. 

Consider another example: [•]; while u < h' do skip; /ow := 1. As in the previous 
example, the value of u may change the reachability of low := 1. Assuming the attacker 
can observe divergence, this is not a pure availability attack, because diverging before the 
last assignment gives the attacker additional secret information, namely that u < h' . New 
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Figure 5. Similar attacks and traces 

information is also obtained if the attacker sees the low assignment. We name attacks 
like this progress attacks. In general, a progress attack is an attack that leads to program 
divergence in a way that observing that divergence (i.e., detecting there is no progress) gives 
new knowledge to the attacker. 



3.2. Attacker control 

We represent attacker control as a set of attacks that are similar in their influence on knowl- 
edge. Intuitively, if a program leaks no information to the attacker, the control corresponds 
to all possible attacks. In general, the more attacks are similar, the less influence the at- 
tacker has. Moreover, the control is a temporal property and depends on the trace that has 
been currently produced. The longer a trace is, the more influence an attack may have, and 
the smaller the control set is. 



Similar attacks. The key element in the definition of control is specifying when two attacks 
are similar. Given a program c[«], memory m, consider two attacks a and b that produce 
traces t and g* respectively: 

{c{a\,m) — ?j- and (c[6],m) — f^ 

We compare a and b based on how they change attacker knowledge along their respective 
traces. First, if knowledge is preserved along a subtrace of one of the traces, say i, it must 
be preserved along a subtrace of q as well. Second, if at some point in t there is a release 
event {x,v)^ there must be a matching low event (x,u) in g, and the attacks are similar 
along the rest of the traces. 

Visually, this requirement is described by the two diagrams in Figure [5} Each diagram 
shows the change of knowledge as more low events are produced. Here the x-axis corre- 
sponds to low events, and the y-axis reflects the attacker's uncertainty about initial secrets. 
Whenever one of the traces reaches a release event, depicted by vertical drops, there must 
be a corresponding low event in the other trace, such that the two events agree. This is 
depicted by the dashed lines between the two diagrams. 

Formally, these requirements are stated using the following definitions. 

Definition 3.3 (Knowledge segmentation). Given a program c, memory m, and a trace t, a 
sequence of indices ]5i . . .pN such that Pi < P2- ■ ■ < PN and tp = li...p-^tp^+i...p2 ■ ■ ■ ^piv_i+i...pjv 
is called 

• progress-sensitive knowledge segmentation of size A'^, if 
Vj < N,\/i . Pj^i + 1 < i < Pj . k{c,mp,£i) = A;(c, mp,£j+i), denoted by 
Seg{c,m,t,pi...pN)- 
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• progress-insensitive knowledge segmentation of size N if 

Vj < N,\/i . Pj-i + 1 < i < Pj . k^{c,mp,£i) = k{c,mp,ii^i), denoted by 
Seg^{c,m,t,pi...pN)- 
Low events Pi + 1 for 1 < i < N are called segmentation events. 

Note that given a trace, there can be more than one way to segment it, and for every 
trace consisting of n low events, this can be trivially achieved by a segmentation of size re. 
We use knowledge segmentation to define attack similarity: 

Definition 3.4 (Similar attacks and traces ^'^^•l'™ ). Given a program c[»], memory rre, and 
two attacks a and b that produce traces t and q, define a and b as similar along t and q 
for the progress-sensitive attacker, if there are two segmentations pi . . . pn and p'l- ■ ■ p'j^ (for 
some A'^) such that 

• Seg{c[a],m,t,pi ...pn), 

• Seg{c[b],m,q,p[ . . .p'^), and 

• Vi . 1 < i < iV . tpp.+i = qpp'.+i- 

For the progress-insensitive attacker, the definition is similar except that it uses progress- 
insensitive segmentation Se^-^. If two attack-trace pairs are similar, we write {a,i) ~'^[*1''^ 
{b,q) (for progress-insensitive similarity, (a, t) ~J^*^''" (b,q)). 



The construction of Definitions |3.3| and |3.4| can be illustrated by program 

[•]; if u then (while h < 100 do skip) else skip; lowi := 0; I0W2 := h > 100 

Consider memory with m{h) = 555, and two attacks ai = u := 1, and a2 = u := 0. 
Both attacks reach the assignments to low variables. However, for 02 the assignment to 
I0W2 is a progress-insensitive release event, while for ai the knowledge changes at an earlier 
assignment. 

Attacker control. We define attacker control with respect to an attack a and a trace t as 
the set of attacks that are similar to the given attack in its influence on knowledge. 

Definition 3.5 (Attacker control (progress-sensitive)). 

Ric[i],m, a, i)^{b\ 3q . {a, t) ~^M'- (6, q)} 

To illustrate how attacker control changes, consider program [•]; low := u < h; low' := h 
where u is an untrusted variable and /i is a secret trusted variable. To understand attacker 
control of this program, we consider an initial memory m{h) = 7 and attack a = u := 5. 
The low event (low, 1) in this trace is a release event. The attacker control is the set of all 
attacks that are similar to a and trace [(u := 5)], (low, 1) in its influence on knowledge. This 
corresponds to attacks that set u to values such that u < 7. The assignment to low' changes 
attacker knowledge as well, but the information that the attacker gets does not depend on 
the attack: any trace starting in m and reaching the second assignment produces the low 
event (low', 7); hence, the attacker control does not change at that event. 

Consider the same example but with the two assignments swapped: [•]; low' := h; low := 
u < h. The assignment to low' is a release event that the attacker cannot affect. Hence 
the control includes all attacks that reach this assignment. The result of the assignment to 
low depends on u. However, this result does not change attacker knowledge. Indeed, in this 
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Figure 6. Release control and robustness 



program, the second assignment is not a release event at all. Therefore, the attacker control 
is simply all attacks that reach the first assignment. 

Progress-insensitive control. For progress-insensitive security, attacker control is defined 
similarly using the progress-insensitive comparison of attacks. 

Definition 3.6 (Attacker control (progress- insensitive) ) . 

R^{c[i\,m,a,^ ^ {b I 3q. (a,t) -fl'™ {b,q))} 

Consider program [•]; while u < h do skip; low := 1. Here, any attack produces a 
trace that preserves progress-insensitive noninterference. If the loop is taken, the program 
produces no low events, hence, it gives no new knowledge to the attacker. If the loop is not 
taken, and the low assignment is reached, this assignment preserves attacker knowledge in 
a progress-insensitive way. Therefore, the attacker control is all attacks. 

4. Robustness 

Release control. This section defines release control R^, which captures the attacker's influ- 
ence on release events. Intuitively, release control expresses the extent to which an attacker 
can affect the decision to produce some release event. 

Definition 4.1 (Progress-sensitive release control ). 

R''{c[i\,m,a,^ ={b\3q. (a,f) -^W''™ (b,q) A 

(3r' . k{c[b],mv,qp) D A;(c[6],mp,gp-rV) 
V k{c[b],mp,qf>) D k{c[b],mp,qp f) 
V(c[6],m)^)} 



The definition for release control is based on the one for attacker control with the three 
additional clauses, explained below. These clauses restrict the set of attacks to those that 
either terminate or produce a release event. Because the progress-sensitive attacker can also 
learn new information by observing divergence, the definition contains an additional clause 
(on the third line) that uses divergence knowledge to reflect that. 

Figure [6a] depicts the relationship between release control and attacker control, where 
the X-axis corresponds to low events, and the y-axis corresponds to attacks. The solid line 
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depicts attacker control R, where vertical lines correspond to release events. The gray area 
denotes release control B!^. In general, for a given attack a and a corresponding trace t-f, 
where f contains a release event, we have the following relation between release control and 
attacker control: 

R{c[i],m,a,r) 5 R''{c[i],m,a,i) D R{c[i],m,a,t-r) (4.1) 

Note the white gaps and the gray release control above the dotted lines on Figure [6a] 
The white gaps correspond to difference R{c[»\,m,a,t) \ R'^{c[»\,m,a,t). This is a set of 
attacks that do not produce further release events and that diverge without giving any new 
information to the attacker — pure availability attacks. The gray zones above the dotted 
lines are more interesting. Every such zone corresponds to the difference R'^[c[»\,m,a,i) \ 
R{c[»],m,a,t-r). In particular, when this set is non-empty, the attacker can launch attacks 



corresponding to each of the last three lines of Definition 4.1 

(1) either trigger a different release event r', or 

(2) cause program to diverge in a way that also releases information, or 

(3) prevent a release event from happening in a way that leads to program termination 
Absence of such attacks constitutes the basis for our security conditions in Definitions 4.3 



and 4.4 Before moving on to these definitions, we introduce the progress-insensitive variant 



of release control. 

Definition 4.2 (Release control (progress- insensitive) ) . 

R''_^{c[i\,m, a, ^^{b\3q. (a, t) -f^'™ (6, q) A 

(3r' . k^{c[b],mf,qp) D k{c[b],mp,qp-r'f>) V {c[b],m) |l)} 



This definition uses the progress-insensitive variants of similar attacks and release events. It 
also does not account for knowledge obtained from divergence. 

With the definition of release control at hand we can now define semantic conditions for 
robustness. The intuition is that all attacks leading to release events should lead to the same 
release event. Formally, this is defined as inclusion of release control into attacker control, 
where release control is computed on the prefix of the trace without a release event. 

Definition 4.3 (Progress-sensitive robustness). Program c[»] satisfies progress-sensitive ro- 
bustness if for all memories m, attacks a, and traces tf, such that {c[a],m) — fj^c',m') — ff 
and f contains a release event, i.e., k{c[a],mp,tf>) D k{c[a],mf,tp-rp), we have 

R'^icl^ljUijU,!) C R[c[i\,m,a,t-f) 



Note that because of Equation 4.1, set inclusion in the above definition could be replaced 



with strict equality, but we use C for compatibility with future definitions. Figure 6b 
illustrates the relation between release control and attacker control for robust programs. 
Note how release control is bounded by the attacker control at the next release event. 
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Examples. We illustrate the definition of robustness with a few examples. 

Consider program [•]; low := u < h, and memory such that m(h) = 7. This program is 



rejected by Definition 4.3 To see this, pick an a = u := 5, and consider the part of the trace 
preceding the low assignment. Release control E!^{c[»],m, a, [(n, 5)]) is all attacks that reach 
the assignment to low. On the other hand, the attacker control i?(c[»], m, a, [{u, 5)]-{low, 1)) 
is the set of all attacks where u < 7, which is smaller than B!^. Therefore this program does 
not satisfy the condition. 

Program [•];/ot(; := h;low' := u < h satisfies robustness. The only release event 
here corresponds to the first assignment. However, because the knowledge given by that 
assignment does not depend on untrusted variables, the release control includes all attacks 
that reach the assignment. 

Program [•]; if li > then low := h else skip is rejected. Consider memory ?7i(/i) = 7, 
and attack a = u := 1 that leads to low trace [{u, l)]-{low, 7). The attacker control for this 
attack and trace is the set of all attacks such that u > 0. On the other hand, release control 
Ft{c[*\,m, a, [(ti, 1)]) is the set of all attacks that lead to termination, which includes attacks 
such that li < 0. Therefore, the release control corresponds to a bigger set than the attacker 
control. 

Program [•]; while n > do skip; low := h is accepted. Depending on the attacker- 
controlled variable the release event is reached. However, this is an example of availability 



attack, which is ignored by Definition 4.3 



Program [•]; while u > h do skip; low := 1 is rejected. Any attack leading to the 
low assignment restricts the control to attacks such that u < h. However, release control 
includes attacks u > h, because the attacker learns information from divergence. 



The definition of progress-insensitive robustness is similar to Definition 4.3 but uses 
progress-insensitive variants of release events, control, and release control. As a result, 
program [•]; while u > h do skip; low := 1 is accepted: attacker control is all attacks. 

Definition 4.4 (Progress-insensitive robustness). Program c[«] satisfies progress-insensitive 
robustness if for all memories m, attacks a, and traces tf, such that {c[a],m) — ^t{c', m!) — f^ 
and f contains a release event, i.e., A;_>>(c[a], mp, tp) D /i:(c[a],r?T,p,ip-rp), we have 

i?'^(c[»],?TT,, a, t) C i2^(c[»],m, a, t-r) 



5. Endorsement 

This section extends the semantic policies for robustness in a way that allows endorsing 
attacker-provided values. 

Syntax and semantics. We add endorsement to the language: 

c[«] ::= ... I X := endorse^ (e) 

We assume that every endorsement in the program source has a unique endorsement label 
rj. Semantically, endorsements produce endorsement events, denoted hy endorse{r],v), which 
record the label of the endorsement statement rj together with the value v that is endorsed. 

(e,m) I V 

{x := endorse^(e),m) — >endorse{r,,v){stop,m[x ^ v]) 
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Whenever the endorsement label is unimportant, we omit it from the examples. Note that 
endorse{T],v) events need not mention variable name x since that information is implied by 
the unique label ij. 

Consider example program [•]; low := endorse^^(u < h). This program does not satisfy 



Definition 4.3 The reasoning for this is exactly the same as for program [•]; low := u < h 
from Section |4] 

Irrelevant attacks. Endorsement of certain values gives attacker some control over the 
knowledge. The key technical element of this section is the notion of irrelevant attacks., 
which defines the set of attacks that are endorsed, and that are therefore excluded when 
comparing attacker control with release control. We define irrelevant attacks formally be- 
low, based on the trace that is produced by a program. 

Given a program c[»], starting memory m, and a trace t, irrelevant attacks, denoted 
here by <I>(c[»],m, t), are the attacks that lead to the same sequence of endorsement events 
as in t, until they necessarily disagree on one of the endorsements. Because the influence of 
these attacks is reflected at endorsement events, we exclude them from consideration when 
comparing with attacker control. 

We start by defining irrelevant traces. Given a trace t, irrelevant traces for t are all traces 
t' that agree with t on some prefix of endorsement events until they necessarily disagree on 
some endorsement. We define this set as follows. 

Definition 5.1 (Irrelevant traces). Given a trace t, where endorsements are marked as 
endorse{r]j,Vj), define a set of irrelevant traces based on the number of endorsements in 

t as 0j(t): 4'o{t) = 0, and 

4'i{^ = {f I t' = q- endorse{r]i,v[)-q'^ such that 

g is a prefix of t' with i — 1 events all of which agree with endorse events in t, and 

Define (f){i) = \j^4'i{t) as a set of irrelevant traces w.r.t. t. 

With the definition of irrelevant traces at hand, we can define irrelevant attacks: irrel- 
evant attacks are attacks that lead to irrelevant traces. 

Definition 5.2 (Irrelevant attacks). Given a program c[»], initial memory tti, and a trace 
t, such that (c[»],m,) — ?^, define irrelevant attacks <I>(c[»], m, t) as 

$(c[.], m, t) = {a I {c[a],m)^^, At' £ (/.(t)} 



Security. The security conditions for robustness can now be adjusted to accommodate en- 
dorsements that happen along traces. The idea is to exclude irrelevant attacks from the 



left-hand side of Definitions 4.3 and 4.4 This security condition, which has both progress- 
sensitive and progress-insensitive versions, expresses roughly the same idea as qualified ro- 
bustness [16J, but in a more natural and direct way. 

Definition 5.3 (Progress-sensitive robustness with endorsements). Program c[»] satisfies 
progress-sensitive robustness with endorsement if for all memories m, attacks a, and traces 
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tf, such that {c[d],m) — f^c',m') — fp and r contains a release event, i.e., A;(c[a],mp,ip) D 
/c(c[a],mp, tp-rp), we have 

-R'^(c[«],7Ti,, a,i)\ ^{c[i],m,t-f) C R[c[»\, m, a,t-f) 



We refer to the set i?^(c 
to 



, m 



,a,i)\ ^{cliljrrijt-r) as a set of relevant attacks. Figures 



7c visualize irrelevant attacks and the semantic condition of Definition 5.3 Figure 



shows the set of irrelevant attacks, depicted by the shaded gray area. This set increases at 
endorsement events marked by stars. Figure [7b] shows an example trace where robustness is 
not satisfied — the gray area corresponding to release control R^ exceeds the attacker control 



(depicted by the solid line). Finally, in Figure 7c we superimpose Figures 7a and 7b This 
illustrates that when the set of irrelevant attacks is excluded from the release control (the 
area under white dashed lines), the program is accepted by robustness with endorsements. 



Examples. Program [•];low := endorse^j(u < h) is accepted by Definition 5.3 Consider 
initial memory m{h) = 7, and an attack u := 1; this produces a trace [{u, l)]endorse{r]i, 1). 
The endorsed assignment also produces a release event. We have that 

• Release control R^ is the set of all attacks that reach the low assignment. 

• Irrelevant traces (^{[{u, l)]endorse{r]i, 1)) is a set of traces that end in endorsement event 
endorse{r]i,v) such that v ^ 1. Thus, irrelevant attacks $([•]; /oio := endorse^j(ti < 
h),m, [{u, l)]endorse{r]i, 1)) must consist of attacks that reach the low assignment and set 
u to values u >7. 

• The left-hand side of Definition 15. 31 is therefore the set of attacks that reach the endorse- 
ment and set u to n < 7. 

• As for the attacker control on the right-hand side, it consists of attacks that set u < 7. 



Hence, the set inclusion of Definition 5.3 holds and the program is accepted. 

Program [•]; low := endorse^^(n); low' := u < h" is accepted. The endorsement in the first 
assignment implies that all relevant attacks must agree on the value of u, and, consequently, 
they agree on the value of u < h" , which gets assigned to low'. This also means that relevant 
attacks belong to the attacker control (which contains all attacks that agree on u < h"). 

Program [•]; low := endorse^^(ii < h); low' := u < h" is rejected. Take initial memory 
such that m{h) ^ m{h'). The set of relevant attacks after the second assignment contains 
attacks that agree on u < h (due to the endorsement), but not necessarily on u < h". The 
latter, however, is the requirement for the attacks that belong to the attacker control. 
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Program [•];!£ u > then h' := endorse(n) else skip; /ow := h' < h is rejected. 
Assume initial memory where m(/i) = m{h') = 7. Consider attack oi that sets n := 1 and 
consider the trace ti that it gives. This trace endorses u in the then branch, overwrites the 
value of h' with 1, and produces a release event (low, 1). Consider another attack a2 that sets 
u := 0, and consider the corresponding trace t2- This trace contains release event {low,0) 
without any endorsements. Now, attacker control R{c[i],m,a2,t2) excludes ai, because of 
the disagreement at the release event. At the same time, ai is a relevant attack for 02, 
because no endorsements happen along t2- 

Consider program c[«], which contains no endorsements. In this case, for all possible 
traces t, we have that (f){t) = </>o(i) = 0- Therefore, by Definition 



5.2 



it must be that 



$(c[«], m,t) =$ for all memories m and traces t. This indicates that for programs without 



endorsements, progress-sensitive robustness with endorsements (Definition 5.3) conserva- 
tively reduces to the earlier definition of progress-sensitive robustness (Definition 4.3). 

Progress-insensitive robustness with endorsement is defined similarly. The intuition for 
the definition remains the same, while we use progress-insensitive variants of progress control 
and control: 

Definition 5.4 (Progress-insensitive robustness with endorsement). Program c[»] satisfies 
progress-insensitive robustness with endorsement if for all memories tti, attacks a, and traces 
tr, such that {c\a\,m) — ?f(c', m!) — f^, and r contains a release event, i.e., A;_j>(c[a], mp, ip) D 
A:(c[a],7Tip, tp-rp), we have 

-R'^(c[»],m, d,t)\ <l>(c[»],m, t-r) C i?_^(c[»],m,, a, t-r) 
As a final note in this section, observe that because of the particular use of irrelevant 



attacks in Definitions 5.3 and 5.4 it is sufficient for us to define irrelevant traces so that they 



only match at the endorsement events. A slightly more generalized notion of irrelevance 



would require g in Definition 5.1 to be similar to a prefix of t' . 



6. Enforcement 

We now explore how to enforce robustness using a security type system. While this section 
focuses on progress-insensitive enforcement, it is possible to refine the type system to deal 
with progress sensitivity (modulo availability attacks) \2Q\ I19| . Figures ^ and p] display 
typing rules for expressions and commands. This type system is based on the one of [16] 
and is similar to many standard security type systems. 

Declassification. We extend the language with a language construct for declassification of 
expressions declassif y(e). Whereas in earlier examples, we considered an assignment I := h 
to be secure if it did not violate robustness, we now require information flows from public 
to secret to be mediated by declassification. We note that declassification has no additional 
semantics and, in the context of our simple language, can be inferred automatically. This 
may be achieved by placing declassifications in public assignments that appear in trusted 
code, i.e., in non-» parts of the program. Moreover, making declassification explicit has the 
following motivations: 

(1) On the enforcement level, the type system conveniently ensures that a non-progress re- 
lease event may happen only at declassification. All other assignments preserve progress- 
insensitive knowledge. 
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r h declassif y(e) : £ n (P, U), vars{e) 
Figure 8. Type system: expressions 



(T-SKIP) 
r, pc h skip 



(T-SEQ) 

T,pc \- c\ r,pc h C2 
r,pcl- ci;c2 



(T-ASGMT) 

rhe:^,D ^UpcC r(x) "iy £ D . T{y) C (§, T) D / ^ pc C (P, T) 

r,pc h X := e 

(T-IF) (T-WHILE) 

rhe:£,0 r,pcU£hci r,pcU£hc2 rhe:^,0 r,pcU£hc 

r,pc h if e then ci else C2 r,pc h while e do c 

(T-HOLE) (T-ENDORSE) 

pcE(P,U) pcur(x) C (S,T) pcCr(x) rhe:^,0 £n(§,T)cr(x) 

r,pc h • r,|?c h X := endorse(e) 

Figure 9. Type system: commands 

(2) Much of the related work on language-based declassification policies uses similar type 
systems. Showing our security policies can be enforced using such systems makes the 
results more general. 

Typing of expressions. Type rules for expressions have form T \- e : (.,D where d. is the level 

of the expression, and D \s a, set of variables that may be declassified. The declassification 

is the most interesting rule among expressions. It downgrades the confidentiality level of 

the expression by returning £ Fl (P,1U), and counts all variables in e as declassified. 

Typing of commands. The typmg judgments for commands have the form F, pc h c. The 

rules are standard for a security type system. We highlight typing of assignments, endorse- 
ment, and holes. 

Assignments have two extra clauses for when the assigned expression contains a de- 
classification (Z? 7^ 0). The rule (T-ASGMT) requires all variables that can be declassified 
have high integrity. The rule also bounds the pc-label by (P,T), which enforces that no 
declassification happens in untrusted or secret contexts. These requirements guarantee that 
the information released by the declassification does not directly depend on the attacker- 
controlled variables. 



18 A. ASKAROV AND A. C. MYERS 



Sequential composition 1 ►- Advancement Lemma ►• Proposition 1 



Sequential composition 2 Control backbone Lemma 

Figure 10. High-level structure of proof of Proposition 



6.1 



The typing rule for endorsement (T-ENDORSE) requires that the pc-lahel is trusted 
and that the result of the endorsement is stored in a trusted variable: pc U T{x) C (§,T). 
Note that requiring a trusted pc-label is crucial, while the restriction that x is trusted could 
easily be lifted, since trusted values may flow into untrusted variables. Because endorsed 
expressions preserve their confidentiality level, we also check that x has the right security 
level to store the result of the expression. This is done by demanding that in (§, T) C T(x), 
where taking meet of i and (S,T) boosts integrity, but keeps the confidentiality level of i. 

The rule for holes forbids placing attacker-provided code in high confidentiality contexts. 
For simplicity, we disallow declassification in the guards of if and while. 

6.1. Soundness 

This section shows that the type system of Figures |8] and [9] is sound. We formulate top-level 



soundness in Proposition 6.1 The proof of Proposition |6 . 1 1 appears in the end of the section. 

Proposition 6.1. IfT,pc h c[»] then for all attacks a, memories m, and traces t-r produced 
by {c[a],m), where k^{c[a],mp,tp) D k{c[a],mf>,tp-rp), we have that 

R'\^{c[i],m, a,i)\ ^{c[»],m,t-r) C i?_^(c[»],m, a, t-r) 



Auxiliary definitions. We introduce an auxiliary definition of progress-insensitive noninter- 
ference along a part of a trace, abbreviated PINI, which we will use in the proof of Propo- 



sition 6.1 Figure 10 shows the high-level structure of the proof. We define declassification 



events to be low events that involve declassifications. The central property of this proof 



the control backbone lemma (Lemma 6.8) — captures the behavior of similar attacks 



and traces that are generated by well-typed commands. Together with the Advancement 
Lemma, it shows that declassification events soundly approximate release events. The proof 
of Proposition |6.1 1 follows directly from the Control Backbone and Advancement lemmas. 

Definition 6.2 (Progress-insensitive noninterference along a part of a trace). Given a pro- 
gram c, memory m, and two traces t and t"*" such that t~^ is an extension of t, we say that 
c satisfies progress-insensitive noninterference along the part of the trace from t to t"*", de- 
noted by PINI(c, m, tji"*") whenever for the low events in the corresponding traces £„ = tp 

and i^ — t^ ,n < N, it holds that 

\/i . n < i < N . k^{c,mp,ii) C k{c,mp,ii+i) 

Lemma 6.3 (Noninterference for no declassifications). Given a program c without declas- 
sifications such that T,pc h c then for all memories m and possible low events i-i' such 
that 

{c,m)^*^c',m')^*,,{c",m") 

it holds that k^{c,m,i) C k{c,m,i-i'). 
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Proof. By induction on c (cf. [Ij). □ 

Lemma 6.4 (Noninterference for the tail of sequential composition). Assume a program c 
such that for all memories m and low events i, such that {c,m) — fi{c',m'), it holds that 
k^(c,mp,€) C k{c,m.p,i). Then for all programs cq, initial memories i, and low events Iq, 
such that 

(co; c, i) — ?^- (c, i') — ^*^' 

we have k^{co;c,ip,£o) C k{co;c,ip,£o-£'). 



Proof. Assume the set inclusion of the lemma's statement does not hold. By Definition 2.2 
there must exist an initial memory m, such that m =p i and (co;c, m) — f^ {c,m') — fi'i, 

but i' 7^ I" . Because m =p i and both traces produce io, it must also be that m' =p i'. But 

this also implies that m' k{c,ip,i'), that is, k^{c,ip,e) % k{c,ip,i'), which contradicts 

the main assumption about c. □ 

The following two helper lemmas correspond to the sequential composition sub-cases of 



the Advancement Lemma. Lemma 6.5 captures the special case when the first command 



in the sequential composition Ci[»];c2[»] does not produce a declassification event, while 



Lemma 6.6 considers the general case when a declassification event may be produced by 
either of ci [•] or C2 [•] . 

Lemma 6.5 (Sequential composition 1). Given 

program Co[«] such that T,pc\- cq[»], 

initial memory rriQ, 

two initial attacks do, bo, 

two intermediate configurations (ci[ai]; C2P2], ?n.) and {ci[bi];c2[b2],s) such that 

(co [ao] , mo) — >*p (ci [oi] ; C2 [02] , m) — >*^^ (c2 [02] , m') — ?^y 

(co [bo] , mo) — f-, (ci [61] ; C2 [h] , s) — f^y,^, 

PINI(co[ao],mo,F,t^-4-f/3) 

Pmi{co[bo],mo,q'',q''-qn 

r and r' are declassification events 

bo ^{co[»],mo,t' -ta-tp-r) 



• tl = q'. 








• m =j s 








then q" = qa-qj3 


such that 




• (ci[ai];c2[a2], 


s)- 


-^qAc2[d2] 


,s' 


• '•a* ^ ia-k 








• m! =f s' 









Q/BT 



Proof. By induction on the structure of ci[»]. Case skip is immediate. Consider the other 

cases. 

• case [•] 

In this case Si = ai and 61 = 61. By assumption, ai and 61 are fair attacks, which 
means that ta has no release events and no assignments to trusted variables. Simila rly, 



because no low assignments can be produced when running 61, then by Definition 
there must be s' and qa that would satisfy the demand of the lemma. 



3.2 
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case X := e 

We consider confidentiality and integrity properties separately. 
Confidentiality: We show that even if a low event is possible, it is not a release event. 

We have two cases, based on the confidentiality level of x. 

(a) r(x) = (P,_) 



A low event is generated by the low assignment. By Lemma 6.3 and Lemma 6.4 
the assignment must not be a release event. 

(b) r(x) = (§,_) 

In this case no low events are generated. 
Integrity: Next, we show that the resulting memories agree on trusted values. The two 
cases are 

(a) T{x) = (_,'ir) In this case it must be that r(e) = (_,'!') and, hence, m{e) = s(e). 
Therefore m! =f s'. 

(b) r(x) = (_,U) Assignment to x does not change how memories agree on trusted 
values. 

• case X := endorse^(e) 

We consider the confidentiality and integrity properties of this command separately. 
Confidentiality: Similar to the case for assignment. 
Integrity: We consider two cases. 

(a) r(x) = (_,¥) 

In this case, the trace produces an event endorse{r], v). We note bo $(co[«], mo, t'- 
tai/^)- In particular, we have that q'q"r' ^ ^{t'-toitj^r). If we assume that the current 
command is the i-th endorsement in the trace, we have that q'-q"-r' (f)i{t'-ta-tp-r). 
But we also know that t'^ =f q'^. Because, by the rule (T-ENDORSE), the result 
of endorsement is assigned to trusted variables, this implies that both q' and t' 
must agree on the endorsed values. Therefore, the only possibility with which 
q'-q"-r' (/'j(t) is that q" generates endorse{r],v) as well. This implies that value 
V is assigned to x in both cases, which guarantees that m! =t s' . 

(b) r(x) = (_,U) Not applicable by (T-ENDORSE). 

• case Ca^cp 

By two applications of induction hypothesis: one to c^; {cp; C2[»]) and the other one to 

C/3;C2[»]. 

• case if e then Ctrue else Cfaise 

We have the following cases based on the type of expression e. 

(a) r(e) = (_,¥) 

In this case both branches are taking the same branch and we are done by induction 
hypothesis. 

(b) r(e) = (_,U) 

In this case neither of Ctrue or Cf aise contain declassifications or high integrity assign- 
ments. This guarantees that m! =f s' . 

• case while e do Cioop 

Similar to sequential composition and conditionals. 

D 

Lemma 6.6 (Sequential composition 2). Given 

• program Co[»] such that T,pc\- co[»] 
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initial memory ttiq 

two initial attacks ao,6o 

two intermediate configurations (ci[ai]; C2P2], w-) and {ci[bi];c2[b2],s) such that 

(co [ao] , mo) — fp (ci [ai] ; C2 [02] , m) — f^r, (c'l [a[]; C2 [02] , m') — ^(^_^) (c'/ [a'/] ; C2 [02] , m") 

(co[6o],mo) — ^-,{ci[bi];c2[b2],s) — f^y,{d',s') — >{y,u){d'\s") 

PINI(co[ao],mo,t^,t^-t''') 

mm{co[bolmo,q',q'-q^') 

(x, v) and (y, u) are declassification events 

bo 0$(co[»],mo,f-t^'-(x,v)) 

i^. = q'. 

m =j s 

then 



«'l = 


-a'i 




there is h\ 


such that 


d! = 


c'aA]: 


C2[b2] 


d" = 


- cm 


;C2[^2] 


t". 


= q''. 




m' -- 


=T s' 




m" 


=TS" 





{x,v) = {y,u). 

Proof. By induction on the structure of ci[«]. In the cases of [•], skip, and x := endorse(e) 
no declassification events may be produced, so these cases are impossible. 

• X := e. When Z? = 0, no declassification events may be produced. When D 7^ 0, a 
declassification event is produced by both traces. Also, t" = q" = e, and m' = m and 
s' = s. Because m =j s and r(e) = (_,T) we have that both traces produces the same 
declassification event {x,v), and therefore, m" =j s" . 

• case c„[aQ,];c/3[a/3] 

We have two cases depending on whether CQ,[aQ,] generates low events: 

(a) {Ca[aa];ici3[ais];c2[a2]),m) — ^*£i...^jv(c/3[a/3]; C2[a2], m') In this case by Lemma [aSJ it 
must be that {Ca[ba];ici3[b(3];c2[b2]),m) — fei...e'^{ci3[bis];c2[b2],s') such that m' =t s' . 
Then we can apply the induction hypothesis to Cj3[»]. 

(b) In this case {x,v) is produced by Ca[aQ] and we are done by application of induction 
hypothesis to Cq[»]. 

• case if e then Ctrue else Cfaise 

We have two cases: 

(a) r(e) = (_,¥) 

In this case both branches take the same command, and we are done by the induction 
hypothesis. 

(b) r(e) = (_,u). 

Impossible, because declassification events are not allowed in untrusted integrity con- 
texts. 

• case while e do Cioop 

Similar to sequential composition and conditionals. 
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D 



Lemma 6.7 (Advancement). Given 

program cq[»] such that T,pc h co[»] 

initial memory mo 

two initial attacks ao,6o 

two intermediate configurations {c[a],m) and {c[b],s) such that 

(co[ao],mo) — f^;{c[a\,m) — f^r,{c'[a'],m') — >(^.^^)(c"[a"], m") 

Fimico[bo],mo,q',q'-q" 

{x, v) and (y, u) are declassification events 

b^^co[i\,mo,i^-f'-{x,v)) 






t'. 


= q'. 


m - 


=T S 


en 
a'-- 


= a" 


there is b' such that 


d'-- 


- c'[b'] 


d" 

t^\ 




m' 


=T s' 


m" 


=TS" 


{x, 


v) = {y,u). 



Proof. By induction on c[»]. In the cases of [•], skip, and x := endorse(e), no declassifi- 
cation events may be produced, so these cases are impossible. 

• X := e. In case D = 0, no declassification events may be produced. When Z) 7^ 0, a 
declassification event is produced by both traces. Also, t" = q" = e, and m! = m and 
s' = s. Because m =j s and r(e) = (_,'ir) we have that both traces produces the same 
declassification event {x,v), and therefore, m" =j s" . 

• case Ca] Cfj 



By Lemma 6.6 



case if e then Ctrue else Cfaise 
We have two cases: 

(a) r(e) = (_,¥) 

In this case both branches take the same command and we are done by induction 
hypothesis. 

(b) r(e) = (_,U). 

Impossible, because declassification events are not allowed in untrusted integrity con- 
texts, 
case while e do Cioop 

Similar to sequential composition and conditionals. 

D 
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Lemma 6.8 (Control Backbone). Given T,pc h c[«], memory m, an initial attack a and a 
trace t, such that 

{c[a],m) — ?p^{ci[ai],mi) — >rAci[ai],m[) — >%-...^^_j 

(c-_i[a'i_i],m._i) — >*f j {cj [aj] , ttij) — >r^ {c'j [a'j] , m[) 

where Vi are declassification events, then for all b,q such that {a,t) r^j^''^ {b,q) and b 
^{c[»],m,i), it holds that the respective configurations (highlighted in boxes here) match at 
the declassification events, that is 



{c[b],m) 



Ql 



(ci[6i],Si) >rAciPl],s\) ?9->2...r,_i 



{ci[bi 



MWils',) 



where i ranges over the number of declassification events in t, and moreover 

• rui =T Si and m[ =t s\ 

Proof. By induction on the number of declassification events. The base case, where n = 0, 
is immediate. For the inductive case, assume the proposition holds for the first n declassifi- 
cation events in t, and apply Lemma 6.7 

D 



We conclude this section with the proof of Proposition 6.1 



Proof of Proposition 6.1 Consider b G RL,{c[ 



,m 



a,i)\ $(c[«],m,, t-r). We want 
to show that b € R-^{c[»\,m,a,t-r). Because b G i?^(c[»],?7i, a, t), we have that b G 

{b\3q. ia,i) -i*^'™ {b,q) A (3P . k^{c[b],mp,qp) D A:(c[6],mp, gp-Pp) V {c[bim) 4)}. We 
consider the two cases 

(1) be{b\ 3q . {a,i) ~^*''™ {b,q) A 3r' . /c_^(c[6],mp,gp) D /c(c[6],mp, gp-r'p)} 

By definition of <^(c[»], m, t-r), we have that b <^(c[»], m, t-r) =^ b <I>(c[»], m,t). 



By the Control Backbone Lemma 6.8, we have that two traces agree on the declassi- 
fication points up to the length of t, and in particular there are tQ,ti, qo,qi such that 
t = to "^i"^ and Q = Qo'Qi and that there are no release events along ti and qi, for which 
it holds that 

and 



where ti, = g^ and m' =j s'. By Advancement Lemma 6.7, we obtain that both traces 
must agree on f and r'. This is sufficient to extend the original partitioning of (a, t) and 
(b,q) to {a,t-f) and (b,qo-qi-r') such that {a, t-r) ~!^*''™ {b,qQ-qi-r'). 
(2) &G{5|3g-'.(a,t)~^*^'™(5,gl A {c[b],m) i^} 



This case is impossible. By the Control Backbone Lemma 6.8 there must be two 
respective configurations {c'[a'],m') and {c'[b'],s') where m' =j s' , such that {c'[a'],m') 
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leads to a release event, but {c'\b'],s') terminates without release events. By analysis of 
c', similar to the Advancement Lemma, we conclude that none of the cases is possible. □ 

7. Checked endorsement 

Realistic applications endorse attacker-provided data based on certain conditions. For in- 
stance, an SQL string that depends on user-provided input is executed if it passes saniti- 
zation, a new password is accepted if the user can provide an old one, and a secret key is 
accepted if nonces match. Because this is a recurring pattern in security-critical applications, 
we argue for language support in the form of checked endorsements. 

This section extends the language with checked endorsements and derives both security 
conditions and a typing rule for them. Moreover, we show checked endorsements can be 
decomposed into a sequence of direct endorsements, and prove that for well-typed programs, 
the semantic conditions for robustness are the same with checked endorsements and with 
unchecked endorsements. 

Syntax and semantics. In the scope of this section, we assume checked endorsements are 
the only endorsement mechanism in the language. We introduce a syntax for checked en- 
dorsements: 

c[»] ::= ... I endorse^(a;) if e then c else c 
The semantics of this command is that a variable x is endorsed if the expression e evaluates 
to true. If the check succeeds, the then branch is taken, and x is assumed to have high 
integrity there. If the check fails, the else branch is taken. As with direct endorsements, 
we assume checked endorsements in program text have unique labels r/. These labels may 
be omitted from the examples, but they are explicit in the semantics. 

Endorsement events. Checked endorsement events checked {ri,v,b) record the unique label 
of the endorsement command rj, the value of variable that can potentially be endorsed v, 
and a result of the check b, which can be either or 1. 

m{e) I V V j^ 

I / \ \ checked{ri,m(x),l) . . 

(endorse^(x) if e then ci else C2,rn) — > {ci,m) 

m{e) I V V = 



I / \ \ checked(rj,m{x),0) . . 

(endorsefy(x) if e then ci else C2,m) — > \C2,m) 



Irrelevant attacks. For checked endorsement we define a suitable notion of irrelevant at- 
tacks. The reasoning behind this is the following. 

(1) Both t and t' reach the same endorsement statement: r]i = r/'. 

(2) At least one of them results in the positive endorsement: hi + h',i > 1. This ensures that 
if both traces do not take the branch then none of the attacks are ignored. 

(3) The endorsed values are different: vi ^ v[. Otherwise, there should be no further 
difference in what the attacker can influence along the trace. 

The following deflnitions formalize the above construction. 
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Definition 7.1 (Irrelevant traces). Given a trace t, where endorsements are labeled as 
checked {t]j,Vj, bj), define a set of irrelevant traces based on the number of checked endorse- 
ments in t as ipi{i). Then ipo{i) = 0, and 

'4'i{^ = {f \ t' = q ■checked{r]i,v^,b',-)-q'} such that 

^is a prefix of t' with i — 1 checked events, all of which agree with checked events in t, 

{hi + h[> l)h{vi^v[),&nd 

q' contains no checked events 

Define ip{^ — Uj 4'i{^ ^s a set of irrelevant traces w.r.t. t. 

Definition 7.2 (Irrelevant attacks ). 'li{c\i\,m,t) = {a\ {c[d],m) — f ^, At' £ ip{t)} 

Using this definition, we can define security conditions for checked robustness. 

Definition 7.3 (Progress-sensitive robustness with checked endorsement). Program c[»] 
satisfies progress-sensitive robustness with checked endorsement if for all memories m and 
all attacks a, such that {c[a],m) — f^{c',m') — ?.^, and r contains a release event, i.e., 
k{c[a],mp,tp) D k{c[a],mp,tp-fp), we have 

R'^{c[i],m, a,t)\ ^{c[i\,m, t-r) C R[c[i\,m, a,t-r) 

The progress-insensitive version is defined similarly, using progress-insensitive definition for 
release events and progress-insensitive versions of control and release control. 

Example. In program [•]; endorse^^(u) if u = u' then low := u < h else skip, the 
attacker can modify u and u'. This program is insecure because the unendorsed, attacker- 



controlled variable u' influences the decision to declassify. To see that Definition 7.3 rejects 
this program, consider running it in memory with m{h) = 7, and two attacks: ai, where 
attacker sets u := 5;u' := 0, and 02, where attacker sets u := 5; u' = 5. Denote the corre- 
sponding traces up to endorsement by ti and ^2- We have ti = [{u, 5)-{u', 0)} checked (rji, 5, 0) 
and t2 = [{u,5) ■ {u' ,5)]- checked {rji, 5,1). Because endorsement in the second trace suc- 
ceeds, this trace also continues with a low event {low,l). Following Definition 7.1 we 
have that ti 'ip(t2- {low,l)), implying ai ^{c[»],m,t2 ■ {low,l)). Therefore, oi G 
R!^{c[i],m, 0,2, t2) \ ^ {c[<i\,'m,t2-{low , 1)). On the other hand, ai i?(c[»],m, a2,t2-{low, 1)) 
because oi can produce no low events corresponding to (low, 1). 

Endorsing multiple variables. The syntax for checked endorsements can be extended to 
multiple variables with the following syntactic sugar, where rji is an endorsement label 
corresponding to variable Xi: 

endorse(xi, . . . x„) if e then ci else C2 =^ endorse^^(a;i) if e then 

endorse^2(x2) if true then . . . ci else skip . . . else C2 

Note that in this encoding the condition is checked as early as possible; an alternative 
encoding here would check the condition in the end. While such encoding would have an 
advantage of type checking immediately, we believe that checking the condition as early as 
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possible avoids spurious (albeit harmless in this simple context) endorsements of all but the 
last variable, and is therefore more faithful semantically. 

Typing checked endorsements. To enforce programs with checked endorsements, we extend 
the type system with the following general rule: 
(T-CHECKED) 

r' = r[a;ih^r(a;,)n(§,T)] T'he:£\D' pc'^pcUi' 

pc' c (s, T) r', pc' h ci r, pc' h C2 

r, pc h endorse(xi, . . . , x„) if e then ci else C2 

The expression e is type-checked in an environment T' in which endorsed variables xi, . . .Xn 
have trusted integrity; its label i' is joined to form auxiliary pc-label pc' . The level of 
pc' must be trusted, ensuring that endorsements happen in a trusted context, and that 
no declassification in e depends on untrusted variables other than the Xj (this effectively 
subsumes the need to check individual variables in D'). Each of the branches is type-checked 
with the program label set to pc'; however, for ci we use the auxiliary typing environment 
r', since the Xi are trusted there. 

Program [•]; endorse(«) if u = u' then low := declassify(n < h) else skip is 
rejected by this type system. Because variable u' is not endorsed, the auxiliary pc-label has 
untrusted integrity. 

7.1. Relation to direct endorsements 

Finally, for well-typed programs we can safely translate checked endorsements to direct en- 
dorsements using a translation in which a checked endorsement of n variables is translated 
to n-|- 1 direct endorsements. First, we unconditionally endorse the result of the check. The 
rest of the endorsements happen in the then branch, before translation of ci. We save the 
results of the endorsements in temporary variables ti . . .tn and replace all occurrences of 
xi . . .Xn within ci with the temporary ones (we assume that each ti has the same confi- 
dentiality level as the corresponding original Xj, and to has the confidentiality level of the 
expression e). All other commands are translated to themselves. 

Definition 7.4 (Labeled translation from checked endorsements to direct endorsements). 
Given a program c[»] that only uses checked endorsements, we define its labeled translation 
to direct endorsements [[c[»]]] inductively: 

• [endorse^ (xi, . . . x„) if e then ci else 02} =^ to '■= endorse^Q(e); if to 
then ti := endorse^^(xi); . . .t„ := endorse^,^(x„); [[ci[tj/xj]]] else IIC2I 

• [ci;c2l^[cil;[c2l 

• [if e then ci else C2I =^ if e then [cij else [[02]] 

• [while e do cj =^ while e do [cj 

• [fcl =^ c, for other commands c. 



Adequacy of translation for checked endorsements for well-typed programs. Next we show 
adequacy of the labeled translation of Definition |7.4| for well-typed programs. Note that for 
non-typed programs this adequacy does not hold, as shown by an example in the end of the 
section. 
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Without loss of generality, we assume checked endorsements have only one variable 



(n = 1 in the translation of checked endorsement in Definition 7.4). We adopt an indexing 
convention where checked endorsement with the label rji, corresponds to two direct endorse- 
ments with the labels rj2i-i and r]2i- The following lemma establishes a connection between 
irrelevant attacks of the source and translated runs. 

Lemma 7.5 (Synchronized endorsements). Given a program c[»] that only uses checked 
endorsements, such that T,pc h c[»], memory m, and attack a, such that 

{c[d],m) — >%- and ([[cp]]], m) — f -^ 

where 

• t = t' -checked {r]i,Vi,bi) and 

• t = t' ■endorse{r]2i-i,0) or t = t' ■endorse{ri2i-i,l)-endorse{r]2i,v) 

• k is a number of checked endorse events in t and 
we have that 

• R{c[i\,m,a,i) = R{lc[»]},m,a,i). 

• R^{c[»],m,a,i) = R^{lc[»]j,m,a,t). 
. $([[c[i']l,m,tl = ^(c[i'],m,t) 

Proof. The first two items follow from the definition of the translation, because the trans- 
lation does not generate new release events. 

To prove the second item, we consider partitions of irrelevant traces generated by every 
k-th checked endorsement and the direct endorsement (s) that correspond to it. We proceed 

by induction on k. For the base case, k = 0, i.e., neither t nor t contain endorsements, 

it holds that $([[c[«]]],m, t) = \I'(c[«],m, t) = 0. For the inductive case, define a pair of 
auxiliary sets 

Fk ^ '^ilc[i]lm,i)\mc[i]lm,?) 
Pk = ^{c[i],m,^\^{c[i],m,i') 



5.2 



and 



7.2 



we 



By the induction hypothesis, ^{c[»],m,t') = ^{c[»],m,t'). By Definitions 

know that <^([[c[»]]], m,t) D $([[c[«]]],m, i') and ^{c[i],m,t) D ^(c[»],m, f). Therefore, in 

order to prove that <I>([[c[»]]],m, t) = ^(c[«], ?7i, t) it is sufficient to show that F^ = P^. We 
consider each direction of equivalence separately. 

* Fk ^ Pk- Take an attack b € Pk- That is (c[6],?n,) produces a trace g such that g agrees 
on all checked endorsements with t except the last one. There are three possible ways in 
which these endorsements may disagree: 
(a) Trace t contains checked{rji.,Vk, 1) and ^contains checked {iji^., u^, 1) such that v^ ^ v'j^. 

By the rules for the translation, it must be that the trace t, which is produced by con- 
figuration ([[c[a]],m), has two corresponding endorsement events endorse(r]2k-i,^) 
and endorse{ri2k,Vk)- Similarly, the trace q, produced by ([[c[6]]], ?7i), has two corre- 
sponding endorsement events endorse{r]2k-i,^) ^-nd endorse{rj2k,v'i^). Because u^ ^ 

Vk we have that g S </>(t). 
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(b) Trace t contains checked endorsement event checked{r]i^, v^, 1), while trace q contains 

event checked{r]k,v'i^,0). In this case, the trace t obtained from running ([[c[a]]], ?7i) 
must contain two endorsement events endorse(r/2fc-i, 1) and endorse{r]2k,Vk), while 
the trace ^corresponding to ([[c[5]]],?7i) contains one event endorse{rj2k-i,0)- There- 
fore, g G </>(*)■ 

(c) Trace t contains checked endorsement event checked {r]ii.,Vk,0), while trace q contains 
event checked {rii^,v'i^, 1). This is similar to the previous case. 

From q ^ (j){t) it follows that b ^ Fj^. 
Fk ^ Pk- Take an attack b G F}^. There must be a trace g, produced by ([[c[6]]],m), such 
that g G 0(i)- There are two ways this can happen: 

(a) q and t disagree at the translated endorsement event that has label r]2k-i- More 
precisely, one must have form endorse{i]2k-i, 1) and the other, endorse{r]2k-i,0)- In 
the original run, this corresponds to two traces t and q such that t contains the 
event checked(r]k,bk,Vk) and q contains the event checked{r]k,b'j^,v'f^). We know that 
bk = 1 and 6^ = 0, and hence bk + b'j^ < 1. According to Definition 7.1, we need to 
show that v'^. ^ Vk- Assume this is not the case, and that w^ = Vk- Then by rule 
(T-CHECKED), we have bk = b'f^, which contradicts the earlier conclusion. Hence 
q£i>{i). 

(b) Alternatively, q and t disagree at the endorsement event that has label r]2k ■ This also 
means that they agree on the earlier endorsement, i.e., for the corresponding trace 
with checked endorsement, we can show that 6^ = 6^ = 1, and Vk i^ v'^. Therefore, 
q^^iS). 

From q^ ^(t) it follows that b ^ Pk- 



Using Lemma 7.5 we can show the following Proposition, which relates the security of the 



source and translated programs. 

Proposition 7.6 (Relation of checked and direct endorsements). Given a program c[»] that 
only uses checked endorsements such that T,pc h c[»], then c[»] satisfies progress-insensitive 
robustness for checked endorsements if and only |Ic[»]]] satisfies progress-insensitive robust- 
ness for direct endorsements. 

Proof. Note that our translation preserves typing: when T,pc h c[»], then T,pc h [[c[»]]]. 



Therefore, by Proposition 6.1 the translated program satisfies progress- insensitive robust- 



ness with endorsements. To show that the source program satisfies the progress-insensitive 



robustness with checked endorsements, we use Lemma 7.5 and note that the corresponding 
sets of irrelevant attacks and control between any two runs of the programs must be in 
sync. □ 

Notes on the adequacy of the translation. We observe two facts about the adequacy of 
this translation. First, for non-typed programs, the relation does not hold. For instance, a 
program like 

[•]; endorse(ii) If u = u' then low := declassify(u < h) else skip 



does not satisfy Definition |7.3[ However, translation of this program satisfies Definition 5.3 
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Second, observe that omitting endorsement of the expression would lead to occlusion. 
Consider an alternative translation that endorses only the variables xi,. . . j;„ but not the 
result of the whole expression. Using such a translation, a program 

if ti • > then skip else skip; trusted := x 

is translated to 

temp := x; if t • > then skip else skip; trusted := x 



However, while the first program does not satisfy Definition 7.3 the second program is 



accepted by Definition 5.3 



8. Attacker impact 

In prior work, robustness controls the attacker's ability to cause information release. In the 
presence of endorsement, the attacker's ability to influence trusted locations also becomes 
an important security issue. To capture this influence, we introduce an integrity dual to 
attacker knowledge, called attacker impact. Similarly to low events, we define trusted events 
as assignments to trusted variables and termination. 

Definition 8.1 (Attacker impact ). Given a program c[»], memory m, and trusted events 
t^, define p(c[«],m, t^) to be a set of attacks a that match trusted events t^: 

p(c[«],m, C) = {a I {c[a],m) — ?^7 A t^ = fj} 

Attacker impact is defined with respect to a given sequence of trusted events t^, starting in 
memory m, and program c[»]. The impact is the set of all attacks that agree with t^ in their 
footprint on trusted variables. 

Intuitively, a smaller set for attacker impact means that the attacker has greater power 
to influence trusted events. Similarly to progress knowledge, we define progress impact, 
characterizing which attacks lead to one more trusted event. This then allows us to define 
robustness conditions for integrity, which have not previously been identified. 

Definition 8.2 (Progress impact). Given a program c[»], memory m, and sequence of 
trusted events t*, define progress impact p_j.(c[»],r?T,, t^,) as 

p^(c[»],m,tv,) = {a I {c[a\,m) — f^{c,m') A t^ = t'j A {c,m) — ?t'j} 

The intuition for the baseline robustness for integrity is that attacker should not influence 
trusted data. This is similar to noninterference for integrity (modulo availability attacks, 
which have not been explored in this context before). However unlike earlier work, we can 
easily extend the notion of integrity robustness to endorsements and checked endorsements. 

Definition 8.3 (Progress-insensitive integrity robustness with endorsements). A program 
c[»] satisfies progress-insensitive robustness for integrity if for all memories m, and for all 
traces t-t^, where t^ is a trusted event, we have 

p^{c[»],m,tT) \$(c[«],m,f-t^) Cp(c[»],m,fT-i*) 

Irrelevant attacks are defined precisely as in Section[5] We omit the corresponding definitions 
for programs without endorsements and with checked endorsements. 
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1 


[•] 


2 


endorse(guess, new_password) 


3 


if (declassify{guess==password) ) 


4 


then 


5 


password = new_password; 


6 


nfailed = 0; 


7 


ok = true; 


8 


else 


9 


nfailed = nfailed + 1; 


10 


ok = false; 



Figure 11. Password update 



1 [•] 

2 endorse ( req_tiine) 

3 if (req_time <= now) 

4 then 

5 if (req_tiine >= embargo_tiine) 

6 then return declassify (new_data) 

7 else return old_data 

8 else 

9 return old_data 

Figure 12. Accessing embar- 
goed information 



The type system of Section [6] also enforces integrity robustness with endorsements, re- 
jecting insecure programs such as t := u and if (ui) then t := endorse(u2), but accepting 
t := endorse(n). Moreover, a connection between checked and direct endorsements, analo- 



gous to Proposition 7.6 holds for integrity robustness too. 



9. Examples 



Password update. Figure 11 shows code for updating a password. The attacker controls 
variables guess of level (P,U) and new_password of level (§,U). The variable password 
has level (S,T) and variables nfailed and ok have level (P, T). The declassification on 
line |3] uses the untrusted variable guess. This variable, however, is listed in the endorse 
clause on line|2| therefore, the declassification is accepted. The initially untrusted variable 
new_password has to be endorsed to update the password on line |5] The example also 
shows how other trusted variables — nfailed and ok — can be updated in the then and else 
branches. 



Data sanitization. Figure 12 shows an annotated version of the code from the introduction, 
in which some information (new_data) is not allowed to be released until time embargo_tinie. 
The attacker-controlled variable is req_time of level (P, U), and new_data has level (S,T). 
The checked endorse ensures that the attacker cannot violate the integrity of the test 
req_tinie >= embargo _tinie. (Variable now is high-integrity and contains the current time). 
Without the checked endorse, the release of new_data would not be permitted either seman- 
tically or by the type system. 



10. Related work 

Prior robustness definitions |16| [TO] . based on equivalence of low traces, do not differentiate 
programs such as [•]; /ow := u < h;low' := h and [•];low' := h;low := u < h; Per 
dimensions of information release [24] , the new security conditions cover not only the "who" 
dimension, but are also sensitive to "where" information release happens. Also, the security 
condition of robustness with endorsement does not suffer from the occlusion problems of 
qualified robustness. Balliu and Mastroeni [B] derive sufficient conditions for robustness 
using weakest precondition semantics. These conditions are not precise enough to distinguish 
the examples above, and, moreover, do not support endorsement. 
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Prior work on robustness semantics defines termination-insensitive security conditions 
|16| [6]. Because the new framework is powerful enough to capture the security of programs 
with intermediate observable events, it can describe the robustness of nonterminating pro- 
grams. Prior work on qualified robustness |16j uses a non-standard scrambling semantics in 
which qualified robustness unfortunately becomes a possibilistic condition, leading to anom- 
alies such as reachability of dead code. The new framework avoids such artifacts because it 
uses a standard, deterministic semantics. 

Checked endorsement was introduced informally in the Swift web application frame- 
work [9j as a convenient way to implement complex security policies. The current paper is 
the first to formalize and to study the properties of checked endorsement. 

Our semantic framework is based on the definition of attacker knowledge, developed 
in prior work introducing gradual release [Ij. Attacker knowledge is used for expressing 
confidentiality policies in recent work [3 IH El [8]. However, none of this work considers 
integrity; applying attacker-centric reasoning to integrity policies is novel. 

11. Conclusion 

We have introduced a new knowledge-based framework for semantic security conditions 
for information security with declassification and endorsement. A key technical innovation 
is characterizing the impact and control of the attacker over information in terms of sets 
of similar attacks. Using this framework, we can express semantic conditions that more 
precisely characterize the security offered by a security type system, and derive a satisfactory 
account of new language features such as checked endorsement. 
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